The field of the present invention relates to data communication networks. In particular, the field of the invention relates to a system for enhancing data communication and for providing ATM service between end stations in a local-area-network service such as IEEE 802.
Data networks relied on shared medium, packet-based local-area-network technologies for both access and backbone connections. The use of packet switching systems such as bridges and routers to connect local-area-networks into a global Internet is now widespread. An Internet router must be capable of processing packets based on many different protocols. The complexities of building networks capable of switching packets on an international network using different protocols places a premium upon efficient implementation of data transfer.
On an Ethernet system, each computer connected to the system, also known as an end-station or work-station, operates independently of all other stations on the local-area-network. There is no central controller. All end-stations attached to an Ethernet are connected to a shared signaling system, also called the medium. Ethernet signals are transmitted over the shared signal channel to every attached station. To send data, a station first listens to the channel, and when the channel is idle the station transmits its data in the form of an Ethernet packet.
After each frame transmission, all stations on the network must contend for the next frame transmission opportunity. This ensures that access to the network channel is fair, and that no single station can lock out the other stations. Access to the shared channel is determined by the media-access-control mechanism embedded in the Ethernet interface located in each station.
The heart of the Ethernet system is the Ethernet frame, which is used to deliver data between end-stations. The frame consists of a set of bits organized into several fields. These fields include address fields, a variable size data field that carries from 46 to 1,500 bytes of data, and an error checking field that checks the integrity of the bits in the frame to make sure that the frame has arrived intact.
The first two fields in the frame carry 48 bit addresses, called the destination and source addresses. The IEEE standard controls the assignment of these addresses by administering a portion of the address field. The 48 bit address is also known as the physical address, hardware address or media-access-control address.
As each Ethernet frame is sent on to the shared Ethernet channel, all Ethernet interfaces look at the first 48 bit field of the frame, which contains the destination address. The interfaces compare the destination address of the frame with their own address. The Ethernet interface with the same address as the destination address in the frame will read in the entire frame and deliver it to the networking software running on that computer. All other network interfaces will stop reading the frame when they discover that the destination address does not match their own address.
A multicast address allows a single Ethernet frame to be received by a group of stations. Network software can set a station's Ethernet interface to recognize a specific multicast address. This makes it possible for a set of stations to be assigned to a multicast group which has been given a specific multicast address. A single packet sent to the multicast address assigned to that group will then be received by all stations in that group.
Ethernet technology is widely used for local-area-networks, and it is common to link such local-area-networks into a wide area network system. An asynchronous-transfer-mode network is one such system. Asynchronous-transfer-mode networks, however, operate very differently than a connectionless Ethernet system. In an Asynchronous-transfer-mode network a point-to-point connection must be established within the network and remains for the duration of the data transfer. Asynchronous-transfer-mode networks are thus connection-oriented as opposed to the connectionless Ethernet system. Furthermore the data is transmitted in short, 53 byte, fixed length cells, not in variable length frames.
In order to use existing local-area-network application software with an asynchronous-transfer-mode network, it is necessary to define an asynchronous-transfer-mode service such as a local-area-network emulation system that emulates services of existing local-area-networks across an asynchronous-transfer-mode network. In a local-area-network emulation service provided for in an asynchronous-transfer-mode network, end-stations such as work stations, servers, bridges, or the like can connect to the asynchronous-transfer-mode network while the software applications interact as if they are attached to a traditional local-area-network. Such service supports inter-connection of asynchronous-transfer-mode networks with traditional local-area-networks by means of well known bridging methods. This achieves inter-operability between software applications residing on asynchronous-transfer-mode attached end-stations and on traditional local-area-network end-stations. The local-area-network service provides a simple and easy means for running existing local-area-network applications in the asynchronous-transfer-mode environment.
In order to facilitate the implementation of asynchronous-transfer-mode networks and utilize their well known advantages, including quality of service control, the cells-in-frames protocol was developed. Cells-in-frames is a method which allows asynchronous-transfer-mode emulation across a local-area-network, the inverse of local-area-network emulation. With cells-in-frames, end-stations attached to a local-area-network such as IEEE 802 can set up asynchronous-transfer-mode connections and send asynchronous-transfer-mode cells across the local-area-network. This is accomplished by encapsulating the fixed length asynchronous-transfer-mode cells within Ethernet frames, thus the name cells-in-frames. The cells-in-frames end-stations package the asynchronous-transfer-mode cells into Ethernet frames and send them over the local-area-network to a cells-in-frames attachment-device. The attachment-device strips the cells from the frames and sends them out over an attached asynchronous-transfer-mode network to the asynchronous-transfer-mode-address indicated by the end-station.
On the Ethernet, cells-in-frames frames have a standard Ethernet version 2 header and trailer. The first eight octets of the frame payload contain the cells-in-frames header, the first octet defining the cells-in-frames format identifier. Only three format types are defined. Format 0 is used for cells-in-frames signaling from the end-stations. Format 1 is used for cells-in-frames signaling from the attachment-device and format 2 is the default format for carrying user traffic. Before user traffic can be transmitted using cells-in-frames, a cells-in-frames link between the transmitting and receiving cells-in-frames devices must be established.
The cells-in-frames end-stations control the process of cells-in frames link activation. The attachment-device only responds to the end-stations messages, it does not initiate any exchanges itself. The cells-in-frames end-station initializes the cells-in-frames link by sending a cells-in-frames format 0 frame. The end-station sends this message periodically until a cells-in-frames attachment-device responds. Neither the cells-in-frames end-station nor the cells-in-frames attachment-device is required to know the other's media-access-control address, thus the cells-in-frames end-station sends this format 0 frame to a media-access-control multicast address that is assigned specifically for the purpose of media-access-control address discovery and link activation.
At the time of link activation, a cells-in-frames attachment-device waits, silently, until it receives a cells-in-frames format 0 frame from a cells-in-frames end-station. When it receives one, it learns that cells-in-frames end-station's individual media-access-control address, as well as the cells-in-frames options the cells-in-frames end-station requests and is willing to support. The cells-in-frames attachment-device begins sending cells-in-frames format 1 frames to this cells-in-frames end-station, using the cells-in-frames end station's individual media-access-control-address as the destination address, and declares the cells-in-frames link to that end-station to be in an up state.
Upon receipt of a cells-in-frames format 1 frame, the cells-in-frames end-station learns the media-access-control address of the cells-in-frames attachment-device, as well as what cells-in-frames options the cells-in-frames attachment-device requests and is willing to support. At that time it declares the link to be up and begins sending only unicast frames destined to the cells-in-frames attachment-device's individual media-access-control address.
Once a cells-in-frames link has been established the transmitting cells-in-frames end-station can begin forwarding cells-in-frames type 2 frames, so called payload frames, to the media-access-control address of the attachment-device. The attachment-device then extracts the asynchronous-transfer-mode cells from the incoming frames and forwards them through the backbone asynchronous-transfer-mode network to their destination asynchronous-transfer-mode address.
One problem with this system arises when a cells-in-frames end-station requests a cells-in-frames connection to a local cells-in-frames end-station, i.e. an end-station attached off the same local-area-network. In this instance the end-station will proceed to establish a link with an attachment-device and setup a link over which to transmit its payload frames. The attachment-device will extract the asynchronous-transfer-mode cells from the payload frames and send them out over the asynchronous-transfer-mode network, not realizing the destination end-station is located on the same local-area-network segment. These cells will be received back by the same attachment-device or another one attached to the same local-area-network, which will reconstruct the frames and forward them to the destination end-station.
This procedure loads down the attachment devices with unnecessary translation of frames to cells and back to frames. Additionally the round-about path taken by the data translates into slower transfer rates and a less efficient network system. What is needed is a method and apparatus for implementing such a method, to short cut forward such local cells-in-frames traffic. Such a method would allow local cells-in-frames end-stations to send cells-in-frames frames directly to each other over the local-area-network.